Communication (whether synchronous or asynchronous) between two computers, or between various components of a computer system, is often accomplished serially, one bit at a time. Yet, microprocessors, microcontrollers and other computing devices handle data bits in parallel (often eight bits at a time), as actual data characters. Therefore, whether data is sent over phone lines, requiring the use of modems, or directly to a peripheral device (such as a serial printer), a communications interface is required, between the "host" processor (parallel data) and the device with which the host communicates, such as a modem or serial printer (serial data).
This interface device must convert is host's outgoing parallel data into serial data bits, and incoming serial data bits into data characters for the host. In addition, it may perform error-checking and various other protocol-related requirements, as well as handle the interfaces with the host system and the serial device with which the host communicates.
Such interface devices are commonly referred to as data communications controllers, or serial controllers, because they control the transmission and receipt of data through one of the host's serial ports (connected to a modem, serial printer or other serial device). Each serial port, or communications "channel, " of the host processor, must be controlled by such a device.
To avoid some of the hardware overhead involved when a separate controller is utilized for each channel, multi-channel devices have been developed. These devices handle multiple communications channels simultaneously, generally by duplicating hardware for each additional channel.
Because data is frequently sent through multiple channels simultaneously, recent multi-channel controllers have come to include hardware data queues ("first-in, first-out" queues or "FIFOs"), for both the transmission and the receipt of data across multiple channels. These FIFOs store data relating to each channel temporarily, until the host processor has time to access such data.
Multi-channel controllers also contain various registers (for storing communications parameters, such as baud rate and size of characters, for each channel), timers/counters (to synchronize the transmission and receipt of data) and mostly random logic to perform the primary tasks of sending/receiving data bits and assembling/disassembling data characters.
Current UARTs, such as the National Semiconductor NS 16550 ACE (Asynchronous Communications Element with FIFOs), and even multi-channel UARTs such as the Signetics SCC2698 Octal UART (eight-channel universal asynchronous receiver/transmitter), provide the host system with little flexibility beyond the setting of parameters (such as baud rate and data character size).
If a user desires to implement a customized protocol, or a collection of differing protocols, current controllers will either perform such tasks inefficiently (due to extensive reliance on the host's processing power--e.g., to implement "Xon/Xoff"data flow control--and an inability to recognize "special" characters, or even modify the the number and size of FIFOs and timers/counters), or be incapable of performing such tasks altogether.
Of interest in this area is the Intel 8273, 8273-4, 8273-8 Programmable HDLC/SDLC Protocol Controller, which, although technically microprogrammed, is built around an architecture dedicated to the HDLC and SDLC synchronous protocols. Employing the same architecture in a UART application, for example, would either be impossible or would result in an extremely inefficient device.
Moreover, current system design techniques necessitate custom controller architectures for custom protocols. Although multiple channels can be supported by such custom controller architectures, this is accomplished by practically duplicating the single-channel architecture for each additional channel.
The result of all of this inflexibility is that users with varying communications requirements end up with either too large a chip (with an excess of unnecessary features) or too small a chip (incapable of meeting the user's requirements).